COMMENT ⊗   VALID 00007 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	SOON
C00013 00003	SOMETIME
C00021 00004	CONSIDER
C00028 00005	CHECK
C00031 00006	DONE
C00032 00007	THOUGHTS
C00034 ENDMK
C⊗;
SOON

Write the fn "Blowup-inv", similar to ...-coa, but for Inverse of fns

Make up a handout of the existing Beings in the system, ∃ parts, what each
	means: the scope of concepts AM starts with
	Supplement: the knowledge/expertise AM has: heuristics, intus,etc.
	Supplement: the activities of AM. What kinds of things it does at top
		level, and the reasoning behind this global orientation.
		EG: why spend a lot of time filling in exs? why spec/genl?
	Supplement: the processes which create new Beings
	Related to this: the new user should have examples of what is expected
		of him. He should be told to always type CRLF,...

Make up a 1-3 page summary of AM: ideas, goals, success criteria, ex scenario.
	What is the overall goal structure?

Almost everywhere:
	exs¬bdy → exs¬
	(exs B) → (acex(a)(ap)  B)
	SELF-INT → ATOM-INT
	FIX(DOTPROD...) → DOTPROD...

Confusion over In-Ran-Of part: does it mean that A is THE range of B,
	A is a subset of the range, A is a superset of the range, A has
	nonzer intersection with the range, A is an element of the range,
	A may be an element of the range, A is an element of a set containing range
	...
	This whole mess is a lot like the confusion which existed about Exs/Spec.

Merge Empty into Empty-struc. Convert Nonempty into Nonempty-struc.
	In genl, any pred of 1 arg over X will be considered a Spec of X.
	In particular, the 2nd feature on Compose.int should retranslate
		from a unary pred to the defn part of any v. int Being.
	The defn parts of actives can be viewed as taking only a single arg,
		a vector of arguments, but that is countr-productive.
	So the unary preds are the defns of objects, of actives with only 1 arg.
	For ordered-objects, the arguments must be chosen and arranged in order.
	That Compose.int feature had better specialize into a specific P fast!!


Only the rejected exs and exs-bdy of related Beings make it into exs¬bdy.
	All the others get pushed into exs¬.
	The Accepted exs-bdy and exs-not and exs-not-bdy of related Beings
		go into the exs-bdy of the Being, not the exs part.
	Random +- examples go into the exs and exs¬ parts.

Coales.sugg + in con-merge-args: int ↑ with the number of args of this fn.
	Don't coa on 2 args which are part of the domain of 1 component fn of
	a composition, since coa(com(f,g)) would then be same as com(coa(f),g).

Map-struc
	Map-struc of Rev-ord-pair should yield Inverse-relation
	Repeatedly inserting the same constant ele into a mult-struc, or 
	repeatedly inserting a new ele into any struc, increases its cardinality
	REPEAT(S Bag-struc-insert(T, B)) would insert ||S|| T's into B (destruc).
	Considering this whole process as F(S,B) (similar to addition), we then
	could do REPEAT(S F(Q,B)), which would replace bag B by one of size
		B + SxQ. Consider the int special case when B starts out Empty.
		The elements of the new B would be S copies of the eles of Q.
	This is multiplication, call it G. Ignore B (say it is always Empty to
		start). Then it is not true that =[G(S,Q), G(Q,S)], but it is
		true that Genl-obj-equal[G(S,Q), G(Q,S)]. This cements Gen= worth.
	Repeating(S, G(Q,R)), we get a bag with Q x R↑S members. The int special
		now is when Q starts out as a singleton, not an empty structure.
	Repeating multiplication, we get hyperexponentiation. Special starter is
		again a singleton bag.

Typs of mapping
	There are 3 flavors of Mapping we might want:
	    (i) Mapc type, where we use one arg out of (S,f)
		as a counter for the number of times we do operation f.
	   (ii)	Mapcar: Replacing each ele in the struc by its f-image.(destruc?)
	  (iii)	Mapconc type: append the results of the op.; maybe destructively
	Of these, the replacement flavor is the most primitive; we are doing a
	parallel type of substitution, with no knowledge or implicit dependence on
	properites of cardinality. Mapping along a list presumes convergence.

Specific details of the Mapping beings
	Some tentaitve defns can be seen on 10/30/75, p25 of red notebook.
	The sticky problem seems to be "initializing" for the operation,
		and also: how to fill in any extra args the op may require.


Conjoin: just conjoin the defn of two Beings. Specializes both of them.
Disjoin: join the defns of 2 B's by "OR". A way of genlizing both of them.
Negate: must be careful not to include everything in universe except 4 things.
        Rule of thumb: unless some explicit reason, only negate if size of negated
   	concept is no bigger than the size of the original concept.
Difference: This is much safer. (AND defn1 ¬defn2) for 2 B's defns.
	E.G.: Difference(All-obj-equal-strucs Empty-strucs) yields Singleton-strucs.
	A common formulation should be: (AND f(x) ¬f(g(x))) or (AND f(g(x)) ¬f(x)).
	For example, here is Singleton:
	(AND (NON-EMPTY-STRUC X) (NOT (NON-EMPTY-STRUC (REMOVE (STRUCTURE-MEMB X) X]

Instantiate: replace variables by constants, fn-calls using other vaiables, etc.
 	In the op SET-STRUC-DELETE, the 2 args are A (ANYTHING) and S (SET-STRUC). 
	We could make this a fn of 1 arg, e.g. by replacing A by either
	a constant or some function of S. I'd like to see it replaced by 
	(STRUCTURE-MEMB S), which would always change S unless it was empty.
	That is, the set of fixed points for this op would be ≡ empty structures.
	Also, another particular use should be in (for some int pred P, ...),
	where P should be replaced by a specific int pred.

Fixed Point: For an operation, when does the value equal a particular arg's value?

DEFN (nec)(suf) parts must be filled in wherever possible, to allow genl/spec/instan

The WORTH components are converted to records. In the code, we might say
	(Setb B 'Worth (Create Worth Aesth←(Add1 (Getb CS-b 'Worth):Aesth)
				     Born←Gcnt
			     (re)Using (Getb CS-B 'Worth]
      OR:  (GETB NEWB 'WORTH):TTIM←(IDIFFERNCE (CLOCK 2)(GETB CS-B 'WORTH):TTIM]



When about to append criteria C (eg int feature) to the defn of B to speclize it,
	first ensure that some examples of B fail that criteria. If not, then:
	(i) mention (and conjecture) that all B's are C-interesting
	(ii) don't actually do the appending, don't create that new spec that way
	(iii) instead, append the negation of C to the definition. Mention
		and record that it is now interesting to find a C-unint B!
		This may require later that other parts of B.defn be relaxed!

When int-specializing a B of the form COA-f, don't USE int features USED on int-f.

When a new pred is created, put it into GINTPREDS. Note that if we just try these
	in order to see if they apply, we'd better let specs precede genls!

User Interaction: V verbosity, N rename, I interest (of cands; of B's), R relnship,
	also: ↑J for multiple queries, will not return after each one like ↑I.

Actually write the intuition scenarios.
SOMETIME

Many compositions are disgustingly unaestheitc. Use several intu scenarios.
	If a composition canzit compose within a scenario, it is ugly.
	If it can, use the resultant aesthetic value to rate the new compos.
	If some plausible inter-scenario bridge is made, tha  is VERY int.

For any Being, the more int it gets, the shorter its name must be,
	and the better that AM must ensure the user really know it.
	E.G.: if a Composition gets int, ask user what he wants to call it.

Ability to decipher Pred Calc defns
	(f a1 a2...) and maybe even f(a1,a2,...) should become (Applyb f 'algs a...)
	The kind of Being that we ar defining (Genl) should help interpret the Defn.
	If the B isa op f:X→Y, then Y will predominate in explaining the Defn.
	For example, if f maps into Structures, then we should expect a defn like
	(∀ vars←$ vstruc←& (iff (Structure-memb v1←& (f vars2←$ vstruc2←&))
			        Realdefn←&).
	In this case, we might want to use a special match-checker, to dynamicaly
	test that vstruc=vstruc2 and vars=vars2,...

Check to see why GEXADD is really needed ever.

The Struc.int feature with 2 args: int should vary as the rareness of satisfying P
	A new feature: when converted to another type of struc, S is int. (° loop)

Relation: viewed as a set of ordered pairs
	Inter-viewing of all of these: Set→Set-of-ord-pairs→Reln→Op
	Should set-of-ord-pairs be a separate kind of structure? discovered?
	Some tentative views: around 10/30/75, p27, red notebook.
	Major stickiness is the finiteness of the set of +- examples available
		to describe a relation. Any more procedural repr would already
		be an operation! So converting a relation to a function is an
		inference problem, and not trivial at all for AM. Going in the
		other direction throws away vast amounts of info, and is nondeter.

If S ⊂ X is int, and some op f maps X (or into X), consider looking at the image 
	(preimage) of S.  Especially if f:X→X. In that case, try to relate S↔f(S).
	Should AM have the concept of preimage? opaquely? discover?
	Maybe get inv-realtion by:
	yεf'(x) ↔ (x,y)εf' ↔ Rev(x,y)εf [defn of f'] ↔ (y,x)εf ↔ xεf(y)
	Inv-op: y=f'(x) ↔ (x,y)εf' ↔ Rev(x,y)εf [defn of f'] ↔ (y,x)εf ↔ x=f(y)

When we operate on S by f:X→X, what we get may or may not share Genls with S.
Not just genls, but any type of property/prdicate/tie/relnship that S satisfied.
	Consider the set of S ⊂ X for which f(S).Genl = S.Genl.
	Consider the set of S ⊂ X for which P(f(S)) = P(S), for some fixed pred P.
(i)	For example, if we perform the operation "inverse-op", is the result still
		an operation, or is it now a relation? Leads to 1-1/bij concept.
	Sometimes inverse(f) fails to be an op because when applied to some y it
	yields the empty result. In that case, we say that f was not ONTO.
	Sometimes it fails because the image of y contains >1 ele; then f wasnt 1-1.
(ii)	Another example: when f:SETS→SETS, consider what happens to SINGLETONS.
	Is the result always a singleton? always empty? never a singleton?
(iii)	Consider the set of all sets for which f(S) is of a given type.
	EG, those sets S for which DELETE(MEMB(S),S) is always a singleton.
	This is the set of doubletons. ...is always EMPTY: EMPTY∪SINGLETONS.
	Conversely, COA-INSERT of EMPTY-STRUCS is never an empty struc,
	COA-INSERT of SINGLETON is never a singleton, ...

If all examples of B seem to be of a certain type, conjec that fact.
	Where to look to consider what types? 
		(i) Study 2 exs in detail, perhaps, and ∩ their properties.
		(ii) In (i), only consider those properties related to B somehow.
		(iii) Find properties related to nephews of B.

When we operate and get a result, see what properties it satisfies/ its genls.
	If some surprising (rare) prop P is satisfied by one or more images, 
	consider the set of all arguements whose images satisfy P.
(i)	The concept of disjoint: those sets whose image under INTERSECT is Empty.

A slight variation: all pairs of results satisfy P(x,y) for some rare/int pred P.
	Or: for all x≠y, P(F(x), F(y)).
	Or:  x≠y iff P(F(x), F(y)).

Of course a very special case is EQUALITY: if f(x)=y, consider the set of all
	z for which f(z)=y.  In the ties part of this new subset X'⊂X, we could
	note in fact (SUBSET X' X). 

The TIES part is a good place to note a relationship involving the concept, for
	which it is not trivially IN-DOM-OF, IN-RAN-OF, EXS, DEFN,... etc.


Altho the Defn part gives a complete N&S defn, maybe for Objects there could
	be  D-R part, which would indicate what types of things to (not to)
	bother applying the defn to. This might really just be the GENL part.
	That is, if it isn't a Genl of this guy, it can't be one of these guys.
	This may already be taken care of implicitly in the Defn facet fn.

To generalize an int-spec of a B, which has ≥2 int predicates tacked onto it,
	remove one (or more), and ensure that the resulting combo is new.

Write some prettyprinting function for a given s-expression. Someone must have one!

CONSIDER


Should we keep some symbolic record of why int values and worth components
	changed? EG: when Compose.int boosts value of P, AM later doesn't
	know WHY P is so int. on an absolute scale. Perhaps keep just keep
	a stack of the last 20 changes; perhaps keep some for each B; perhaps
	asa part on each Being, which can be destroyed like FEX for space reasons;
	perhaps as part of AID part.

Similarly, should we keep a record of why each particular *-bdy entry is not in *?
	Then we could just keep 1 or 2 entries for each separate reason.

Associate a particular D-R entry with a particular ALG; with a partic. INTU

Keep Genl/Spec as two tree structures for the whole system, so that
  for any B, B.GENL just points into this single huge GENL tree.
  This is easy to update if extra parens can be tolerated here and there,
  but otherwise quite tricky to maintain.

Not all compositions and coalescings are going to fall in our space, unless:
(i) we have a Left and a Rightmost Compose operation, or
(ii) con-merge-args computes all (several) possible ways of overlapping the
     domain of op1 with the range of op2. It then ranks these aesthetically,
     eliminates already-existing ones, and returns a LIST of new B's to create.
     Note that this way, COMPOSE is really a relation, not a single-valued op.
(ii) Give AM the knowledge that COMPOSE is associative

May want to keep GINTPREDS sorted by some int/recentness criterion.

Given a predicate on ATOMSxATOMS, to extend it to STRUCSxSTRUCS, consider the
	following recursive defn: 
			F(x,y) ≡ COND((OR (NLISTP x)(NLISTP y)) 
				      (f x y))
				     (T (AND (F (CAR x) (CAR y))
					     (F (CDR x) (CDR y))
					]
	Of course, we could use FIRST and REAR, and we can genlize this easily.
	This would trun EQ into OBJ-EQUAL, ALPHORDER into SORD, ...
	It intuitively checks f at all levels of two nonatomic arguments.
	We must ensure that f can handle one nonatomic arg and one atomic one.
	If it can't, the standard option should be that f returns NIL in that case.
	Actually, (F...) really means (APPLYB F 'ALGS ...).


Can view a predicate of one argument as a SPEC of its domain.
Can view a predicate of 2 arguments as a predicate on the domain of ORD-PAIRS,
	and therefore just a specialization of the set of all ord-pairs. Yichh!
One implication: when looking for an int pred, we just look at Defn of int
	Beings; If 2 args, we look for SPEC of ORD-PAIRS.
A more general way to look at Preds is as Spec of LIST-STRUCS, with predicates
	of n args and 1 T/F result simply as specs of LIST-STRUCS of length n.
Similarly, an op with n args and 1 result is a Spec of Lists of length n+1.


Preds and Defns might return a number, the certainty factor that arg isa B.
	Then use MAX and MIN instead of OR and AND; keep calc. until timeout;
	Another thing to worry about (eg in Fil-struc-p): "non-null subset" 
	now is uncertainly computed as "set of things with hi enuf memb-values"

Is there an easy way to pre-compile all the xs-parts of the primitve Beings,
	so a slow system won't hurt the opening few minutes of a demo?
	Maybe just run the system for a while, then ↑D and (Reset3).
	This of course will use lots of extra time and space, and won't be perm.

Theorem templates: abstract schemata: things like f(g(x,y),z)=f(h(x,y),z).

Use Prod Sys to let AM decide what to do next: unite all Sugg parts into 1 PS.
	the concepts, cands, past are all the memories that the LHS look at.
	the RHS actions can be inserting/modifying entries in those memories.


To check Active-exs: we don't rerun to doublecheck. Is that wise? ok?

There is a minor mixup over Exs vs Exs-bdy vs Acex vs Acexa vs Acexappend...
	Consider some scheme for keeping exs and bdy exs stored together.
	Should there be an alaogue ACEXNOT for non-exs?

Consider having a macro (or even a 1-pass EVAL permanent transformation fn)
	which replaces CPRIN1S calls by PRIN1 calls on 'X if X≠UP-CASE(X),
	else just call PRIN1 on X (which will evaluate it).

CHECK

That it is Ok to completely forget about GREM.

When we check exs of x, eliminate those already on exs(spec(x)). In fact,
	run spec(x).defn on the exs(x) to see if they fit into a more spec place.
	Converse: when checking non-exs and exs-not-bdy of x, elim those already
	on exs-not(genl(x)) and exs-not-bdy(genl(x)). Consider running those
	defns parts of genls, to see if the existing x-failures fail at even a
	more general level.
	Conversely for cousins: doublecheck exs/not with them, get suggestions for
	exs/not from them,...

The CENT of View should be Spec, not Genl. To view x asa y, one may use info which
	views any genl(x) as a spec(y). So what about anyb.view? struc.view?


If B has no defn, we may look at Spec(B).defn. Say one of these is worded
	(AND (ISA x B) ...). Then ISA might try to reapply B.Defn... ∞loop

When filling in a new B's up part, make sure to tag the corresponding exs part
	in the Being pointed to. This cleanup applies in genl to all doubly-linked
	pointer structures (graphs).
 
That the Worth part records get stored and saved and resload properly.
	What about changing the record declaration? What affect does it have?
	Maybe have to create new record type W2, with new decl, reset all fields
		of the W2 record for each Being, then reset Worth decl and
		reset all Worth fields. Ugh!
	Often, Rplacint will be translated into a record assignment statement.

Int-coa-f and Coa-int-f: rcognize their equivalence (when ≡).
	In general, for a new B, find the few B's most likely to be trivially
	equiv, and check. If exs/non-exs overlap, check to see if triv. explan.
	for equiv. The less trivial that explanation, the more int the conjec of ≡.

We're going to eval the int features eventually; see if P must be better/globally
	bound inside the features on COmpose.int.

DONE

A fruitful/int place to find exs of B is ACEX(GENL(B)). In case one passes,
	transfer the example destructively over to B.  If it fails, consider
	incrementing it onto B's exs¬bdy collection.
A fruitful/int place to find exs¬bdy of B is EXS¬(SPEC(B)). In case one misses,
	transfer the example destructively over to B. In case it passes, consider
	adding it to exs-bdy part of B.














THOUGHTS

The more variation one is allowed in writing parts, the more intelligence
flexibility, and costliness of the code required to process, synthesize,
and check that part.
For example, all the following are equivalent:
	COND((A) (T B))
	COND((A) (B))
	(OR A B)
	(OR NIL A B)
	IF (SETQ Z1 (A)) THEN Z1 ELSE (B)
	IF (SETQ Z1 (A)) THEN Z1 ELSE IF (SETQ Z2 (B)) THEN Z2
	IF (SETQ Z1 (A)) THEN Z1 ELSE IF (SETQ Z2 (B)) THEN Z2 ELSE NIL
If we want ALL of them to be "understood", allowable ways of writing A or B,
we must know sores of little facts and be ready to bring them into play:
	In a COND clause, (x) means: if x evals to non-null then return that value.
	In a COND, we go clause by clause until returning, else return NIL.
	A COND clause of the form (x y ... z) means:...
	In an OR, each disjunct is evaluated in order, and we halt when one
		evals to non-null, at which time we return that value; else NIL.
	As the final clause of a Cond, (x) is the same as (T x).
     ...........
	etc.